Processes

The Public Transport program performs the following processes:

Some processes have associated phases which allow you to augment the task with additional context-sensitive computations.

You control the main processes and their associated phases, within a prescribed hierarchy.

Public Transport program processes and associated phases

(With multiple user classes, processes in the blue boxes are performed separately for each class.) See Phases for a description of the phases in the Public Transport program.

You configure the Public Transport program to run through a specific combination of control statements and phases.

Control statements are either static or dynamic. Static statements may be present anywhere in the job stream; the program evaluates them once. Dynamic statements may be present only within phases; the program evaluates them as encountered, during the execution of the phases.

Only context-sensitive dynamic control statements are available to the phases; the description of each phase lists valid control statements (see Phases).

Only code phases that contain control statements; do not code empty phases.

Network development

During network development, the Public Transport program:

Reads in the input network from FILEI NETI.
Processes public transport system data in FILEI SYSTEMI
Processes the LINE control statements in FILEI LINEI
Processes the FACTORS control statements in FILEI FACTORI
Processes the PARAMETERS control statements in the script file
Generates and/or reads nontransit legs with the GENERATE statements.
Develops a comprehensive public transport network from the basic network, public transport system data, lines, nontransit leg, and control information. This includes stringent validation and consistency checks to ensure that the different components of the public transport network are compatible.

The DATAPREP phase is mandatory for public transport network development. The phase provides the control statements for nontransit leg generation and/or input.

Either the Network program or the Public Transport program can produce the input network. However, only zone, node, and link information are taken from networks produce by the Network program; you must provide public transport system, line, and control data.

The components of the public transport network are common to all user classes, except for route-enumeration and route-evaluation control information, which may be provided separately for each class.

See Public transport network development for examples of this task.

Inputs required for Public Transport network development

A network, produced by Network or Public Transport, input with NETI.
Public transport system data, input with SYSTEMI
One or more lines files, input with LINEI[#]
Control information for route enumeration and route evaluation, input with FACTORI (For multiple user classes: control information input with FACTORI[#])
Global parameters input with the PARAMETERS statement
One or more GENERATE statements and, optionally, nontransit legs input with NTLEGI[#]

Outputs produced by Public Transport network development

A public transport network, which may be saved with NETO.
A table of links and their attributes, in DBF format, which may be saved with LINKO.
Nontransit legs (generated and input), which may be saved with NTLEGO. The legs are in the format specified by the NT control statement. Optional PNR, KNR, and drive access results are distinguished by respective mode number specified by user.
A text version of the lines in the public transport system, which may be saved with LINEO. The lines are in the format specified by the LINE control statement.

The Public Transport network is made available to any other processes in the job stream that require it. If trips are loaded in the run creating the public transport network, all output files can optionally contain the results of the loading.

The saved Public Transport network may be used in subsequent runs of the Public Transport program for route enumeration, route evaluation, skimming, loading and loading analyses. It contains all

information required for these processes apart from fares data which may optionally be read later, so allowing it to vary between program runs.

You can use CUBE to display but not edit the Public Transport network.

Associated phases

DATAPREP (mandatory)

Route enumeration

During route enumeration, the Public Transport program identifies sets of discrete routes between zone pairs, which have some probability of being used by passengers to travel between the zones. Route enumeration is a heuristic process, which you control with the FACTORS statement.

This set of discrete routes may be pruned at the route-evaluation stage, in compliance with further user specified controls.

A ROUTEO file in the job stream invokes route enumeration. You can save an enumerated routes file and input the file to a subsequent run with ROUTEI.

When modeling multiple user classes, provide separate FACTORS statements for each class to produce enumerated route files for each class.

By default, Public Transport enumerates routes for all zone pairs. However, you can use ROUTEI and ROUTEO statements to select zone pairs separately for route enumeration and reporting.

See Route-enumeration process for theory about route enumeration.

Inputs required for Public Transport route enumeration

A public transport network file, produced either by the current run of the Public Transport program, or produced previously and input with NETI.

Outputs produced by Public Transport route enumeration

An enumerated routes file, ROUTEO. For multiple user classes, enumerated routes files, ROUTEO[#].

Note: Vast quantities of data can be required to define a public transport system. To improve performance of the main algorithms and minimize memory and temporary disk storage, the data is organized in a highly compressed form for processing and storing routes. The line data is converted into transit legs and the network data into nontransit legs. The simplified network, which is described in Network simplification, can be examined through a series of reports specified on the REREPORT statement.

Associated phases

None

Route evaluation

During route evaluation, the Public Transport program:

Examines enumerated routes
Eliminates any illogical ones that have crept in due to network simplification
Disaggregates bundled routes, where appropriate
Identifies routes that have, at the minimum, a user specified probability of use or more, at every decision point along the route

The route-evaluation process is a prerequisite for the skimming, select-link, loading, and loading-analyses processes. Selecting one or more of these processes automatically invokes the route- evaluation process.

This is because only enumerated routes are saved; they are evaluated as required. (Enumerated routes produced by an earlier run may be input with ROUTEI for evaluation or generated by specifying a filename with ROUTEO).

Evaluated routes may be reported with ROUTEI and ROUTEO. See Route-evaluation process for the theory supporting route evaluation.

Inputs required for Public Transport route evaluation

A public transport network file, produced either by the current run of the Public Transport program, or produced previously and input with NETI.
A route file, produced either by the current run of the Public Transport program, or produced previously and input with ROUTEI. (For multiple user classes, enumerated routes files input with ROUTEI[#]).
Fares data may be read directly into a route-evaluation run.

Note: Any previously built NETI and ROUTEI files that you input must be compatible.

Outputs produced by Public Transport route evaluation1

One or more sets of "attractive" or "reasonable" route bundles
Their probabilities of use
The cost of using the routes

The skimming, select-link, loading, and loading-analyses processes are performed on the fly. Indeed, these are by-products of the route-evaluation process, but described separately, as they report on different aspects of the Public Transport model.

Associated phases

Skimming (level of service)

The skimming process produces skim (level of service) matrices of total trip costs and their components, from the information generated by route evaluation. When modeling multiple user classes, you can produce skims for each class from the individual enumerated route files.

This section is detailed; you may skip ahead to Skim functions — quick reference for a quick reference of the skimming functions.

See also: Skimming arguments and syntax

Computes the average additional wait time due to crowding effects incurred at the transfer points of all "attractive" routes between zones.

The additional wait time occurs when unable to board a service (so needing to wait for the next one) and at the end of modeled period (where demand exceeds capacity causing a bottleneck).

Actual initial wait time

IWAITA(RouteSet)

See also: Skimming arguments and syntax

Computes the average actual wait time incurred at the start of the trip for all "attractive" routes between zones. It is calculated either from one or more wait curves supplied by the WAITCRVDEF control statement, assigned to nodes by IWAITCURVE keyword, or, for nodes that have not been assigned one, from a default wait curve.

Actual transfer wait time

XWAITA(RouteSet)

See also: Skimming arguments and syntax

Computes the average actual wait time incurred at the transfer points of all "attractive" routes between zones. It is calculated either from one or more wait curves supplied by the WAITCRVDEF control statement, assigned to nodes by the IWAITCURVE keyword, or, for nodes that have not been assigned one, from a default wait curve.

Perceived crowding wait time

CWDWAITP(RouteSet)

See also: Skimming arguments and syntax

Computes the average additional wait time due to crowding effects incurred at the transfer points of all "attractive" routes between zones, weighted by the WAITFACTOR keyword.

The additional wait time occurs when unable to board a service (so needing to wait for the next one) and at the end of modeled period (where demand exceeds capacity causing a bottleneck).

Perceived initial wait time

IWAITP(RouteSet)

See also: Skimming arguments and syntax

Computes the average actual time incurred at the start of the trip for all "attractive" routes between zones, weighted by WAITFACTOR. It is calculated either from one or more wait curves supplied by the WAITCRVDEF control statement, assigned to nodes by IWAITCURVE, or, for nodes that have not been assigned one, from a default wait curve.

Perceived transfer wait time

XWAITP(RouteSet)

See also: Skimming arguments and syntax

Computes the average actual time incurred at the transfer points of all "attractive" routes between zones, weighted by WAITFACTOR. It is calculated either from one or more wait curves supplied by the WAITCRVDEF control statement, assigned to nodes by XWAITCURVE, or, for nodes that have not been assigned one, from a default wait curve.

Travel-time skim functions

This section describes travel-time skim functions:

Actual travel time

TIMEA(RouteSet,Mode)

See also: Skimming arguments and syntax

For transit modes, this skim computes the average in-vehicle run time for all "attractive"routes between zones. It is taken from the network link data, factored by any line specific factors.

For nontransit modes, this skim computes the average nontransit time (access, egress and transfer) for all "attractive" routes between zones. It is taken from the nontransit legs generated or read in by the GENERATE statements.

Perceived crowded link travel time

CWDCOSTP(RouteSet,Mode)

See also: Skimming arguments and syntax

For transit modes, this skim extracts the average additional in- vehicle run time for all "attractive" routes between zones. This is the run time that is above the basic calculated in-vehicle time and arises due to crowding effects and crowd factors greater than 1.0. As a perceived data skim, it is taken from the network link data and factored by any line specific factors, RUNFACTOR and Crowding factor.

Perceived travel time

TIMEP(RouteSet,Mode)

See also: Skimming arguments and syntax

For transit modes, this skim extracts the average in-vehicle run time for all "attractive" routes between zones. It is taken from the network link data and factored by any line specific factors, and RUNFACTOR.

For nontransit modes, this skim extracts the average nontransit time (access, egress and transfer) for all "attractive" routes between zones. It is taken from the nontransit legs generated or read in by the GENERATE statements and factored by RUNFACTOR.

Penalty skim functions

This section describes penalty skim functions:

Actual transfer penalty

XFERPENA(RouteSet,Mode)

See also: Skimming arguments and syntax

Extracts the average actual transfer penalty for all "attractive" routes between zones. It is taken from XFERPEN.

Perceived boarding penalty

BRDPEN(RouteSet,Mode)

See also: Skimming arguments and syntax

Counts the boarding penalties associated with transit legs of the trip.

Perceived transfer penalty

XFERPENP(RouteSet,Mode)

See also: Skimming arguments and syntax

This skim is the average perceived transfer penalty for all "attractive" routes between zones. It is the actual penalty as coded in XFERPEN, weighted by XFERFACTOR with XFERCONST added.

Fare skim functions

This section describes fare skim functions:

Monetary units

FAREA(RouteSet,Mode)

See also: Skimming arguments and syntax

Extracts the average fare, in monetary units, for all "attractive" routes between zones. It is calculated from the fare systems used by the "attractive routes". Fares are calculated either by transit leg or for a sequence of legs; in the latter case the fare is apportioned to the legs in proportion to leg distance.

Generalized cost units

FAREP(RouteSet,Mode)

See also: Skimming arguments and syntax

Extracts is the average fare, in generalized cost units, for all "attractive" routes between zones. The fare is calculated as for skim FAREA, from the fare systems used by the "attractive routes", and converted into generalized cost units with mode specific VALUEOFTIME.

Fares are calculated either by transit leg or for a sequence of legs; in the latter case the fare is apportioned to the legs in proportion to leg distance.

Other skim functions

This section describes other available skim functions:

Best trip time

BESTJRNY

See also: Skimming arguments and syntax

Extracts the best actual trip time for zone pairs (that is, at each decision point, the best choice is taken). The trip time comprises:

Walk time — taken from input or generated nontransit legs
Average wait time — actual
In-vehicle time — actual
Boarding penalties
Transfer penalties — actual

Note: The route followed by this best actual trip may differ from that found using BESTPATHONLY as the latter route is selected on cheapest perceived travel cost.

Boardings

BRDINGS(RouteSet,Mode)

See also: Skimming arguments and syntax

Extracts the average number of boardings used by the "attractive" routes between zone pairs.

Composite cost

COMPCOST(RouteSet)

See also: Skimming arguments and syntax

Measures the perceived costs of travelling between zone pairs using all "attractive" routes. It takes into account all choices available at decision points (for example, walk or alighting), and is appropriate for use in demand modeling and the evaluation of schemes. It comprises:

Walk time
Wait time (including any crowding wait time)
Boarding time
Transfer time
In-vehicle time (including any link-crowding effects)
Fares (when PARAMETERS FARE=T)

Distance

DIST(RouteSet,Mode)

See also: Skimming arguments and syntax

Extracts the average distance travelled by the "attractive" routes between zone pairs. It is taken directly from the network link data.

Excess demand

EXCESSDEMAND

See also: Skimming arguments and syntax

Extracts the number of trips (from the demand matrix) which are unable to readily reach their destination due to bottleneck points in the network where demand exceeds capacity, and no viable alternative route is available. It is only available when crowd modeling is performed, and wait time adjustments are used.

It highlights where the public transport system is unable to satisfy the demand flows which are being loaded.

Excess demand as a proportion

EXCESSPROP

See also: Skimming arguments and syntax

Extracts the proportion of trips for each origin-destination pair which are unable to readily reach their destination due to bottleneck points in the network where demand exceeds capacity, and no viable alternative route is available. These trips would need to wait till beyond the modeled period before being able to board their next transit leg.

This skim is only available when crowd modeling is performed, and wait time adjustments are used.

The EXCESSDEMAND skim only gives cell values where demand exists and bottlenecks prevent it reaching the destination. The EXCESSPROP skim highlights movements where the public transport system could well have difficulty in meeting demand (whether or not any demand exists in the loaded matrices).

Value of choice

ValOfChoice(RouteSet)

See also: Skimming arguments and syntax

Indicates level of choice available in the public transport system by computing average travel cost skim minus the composite travel cost skim.

Sample calculation:

ValOfChoice(0) = ((IWAITP(0)+
XWAITP(0)+
TIMEP(0, ALLMODES)+
BRDPEN(0, ALLMODES)+
XFERPENP(0, ALLMODES))-
COMPCOST(0)

Expression contains additional terms when modeling fares or crowds.

Skim functions — quick reference

This section provides a quick reference to the different types of skims or levels-of-service matrices that can be extracted from the "attractive" routes between zones.

See also:

Skimming (level of service) for an introduction to Public Transport skimming.

Skimming arguments and syntax for detailed information on the functions and syntax.

Summary of skim functions

BESTJRNY - Skims best trip times
BRDINGS(RouteSet, Mode) - Skims number of boardings
BRDPEN(RouteSet, Mode) - Skims boarding penalty (perceived)
COMPCOST(RouteSet) - Skims composite costs
CWDCOSTP(RouteSet, Mode) - Skims crowding link travel times (perceived)
CWDWAITA(RouteSet) - Skims crowding wait times (actual)
CWDWAITP(RouteSet) - Skims crowding wait times (perceived)
DIST(RouteSet, Mode) - Skims distance
EXCESSDEMAND - Skims excess demand (where demand exceeds capacity in crowding model)
EXCESSPROP - Skims excess proportion (where demand exceeds capacity in crowding model)
FAREA(RouteSet, Mode) - Skims fares in monetary units
FAREP(RouteSet, Mode) - Skims fares in generalized time units
IWAITA(RouteSet) - Skims initial wait times (actual)
IWAITP(RouteSet) - Skims initial wait times (perceived)
TIMEA(RouteSet, Mode) - Skims travel time (actual)
TIMEP(RouteSet, Mode) - Skims travel time (perceived)
ValOfChoice(RouteSet) - Skims value of choice
XFERPENA(RouteSet, Mode) - Skims transfer penalty (actual)
XFERPENP(RouteSet, Mode) - Skims transfer penalty (perceived)
XWAITA(RouteSet) - Skims transfer wait times (actual)
XWAITP(RouteSet) - Skims transfer times (perceived)

During the loading process, the Public Transport program assigns passenger demand, in the form of trips, to the attractive routes between zone pairs. These routes have their probability of use determined by the route evaluation process with a series of models:

Walk-choice model
Service-frequency or the service-frequency-and-cost model
Alternative-alighting model

The model theory is described in Route-evaluation process and the loading theory is described in Loading process.

Demand may be stratified by user class and loaded to enumerated routes generated either by class or for the whole Public Transport network.

Loading is invoked by assigning, either input or generated trip matrices to TRIPSIJ[#], or trips for individual zone pairs to the variable TRIPSIJ in the SELECTIJ phase.

The results of loading, passenger flows on lines, may be reported with the REPORT statement. This can be done either in the run in which loading was performed or by saving the loaded public transport network and reporting the loads in a subsequent run of the program.

See Public transport loading for an example of this function.

Inputs required for Public Transport loading

Public Transport network file, either produced by the current run of the Public Transport program, or produced previously and input with NETI.
Route file, produced either by the current run of the Public Transport program, or produced previously and input with ROUTEI (for multiple user classes, enumerated routes files input with ROUTEI[#]).

Note: If previously built NETI and ROUTEI files are input, they must be compatible.
Trips for loading onto the routes

These may be input as a trip matrix with MATI, or computed during the run (for multiple user classes, trip matrix files input with MATI[#]).

Outputs produced by Public Transport loading

A loaded Public Transport network with transit and nontransit loads, which may be saved in the file designated by NETO. This network may be displayed by CUBE but not edited.
Loaded nontransit legs, in ASCII format, which may be saved in the file designated by NTLEGO.
Loaded lines, in ASCII format, which may be saved in the file designated by LINEO.
A table of link and their attributes, including loads, in DBF format, which may be saved in the file designated by LINKO.

Associated phases

MATI

Select link

During the select-link process, the Public Transport program produces output matrices of demand matching selection criteria, and can also perform select-link loading.

When you model multiple user classes, this process can produce select link outputs for each class from the individual enumerated route files.

You can also use CUBE Analyst to estimate Public Transport demand matrices. See INTERCEPTO and SCREENLINEO in FILEO for more information.

Inputs required for Public Transport select link

A public transport network file, either produced by the current run of the Public Transport program, or produced previously and input with NETO.
A route file, produced either by the current run of the Public Transport program, or produced previously and input with ROUTEI (for multiple user classes, enumerated routes files input with ROUTEI[#])

Note: If you input previously built NETI and ROUTEI files, they must be compatible.

Outputs produced by Public Transport select link

A matrix file, MATO (for multiple user classes, matrix files, MATO[#])
Loadings, when only that demand which satisfies a select-link criterion is loaded

Associated phases + SKIMIJ (mandatory) + MATO

Select-link Functions

The select-link function provides a range of facilities to identify travel demand using particular links, lines, or nodes in the network. Lines may be identified explicitly or selected based on their mode or operator attributes. Throughout this section the functionality is referred to by the generic term "select link" although in practice it offers a wider range of selection mechanisms.

The select-link function outputs a matrix, containing that demand which satisfies the selection criteria. In a run, you may specify a series of selection criteria, each one being associated for output purposes with a different working matrix. You can save the resulting matrices to the FILEO MATO[n] where n is the user class being evaluated (that is, select link results are saved to the same matrix file as skim outputs).

The process normally considers just transit legs using the link/line, or passing the node. However, if required nontransit legs may be considered, or for nodes the activity may be restricted to specific movements (for example, boarding a transit line).

The select-link criteria are defined as expressions, which allows compound conditions (using and / or / not operations) to be specified.

You may specify additional keywords in the expression to obtain either percentage or proportion of demand (rather than actual demand flow) satisfying the criteria. These allow you to obtain results when demand flows for an I-J pair are zero.

The demand flows loaded onto the network may be restricted to just that demand which meets the selection criteria. This permits the display of demand and loadings which use the selected link. Where several select link functions are used in a run only one of them may contain the keyword which triggers select-link based loading.

The general form of the select-link function is:

SELECTLINK(expression)

where the expression defines the selection criteria. This general form typically appears on the right hand side of a COMP (compute) statement which sets the value of cells in a particular working matrix, for example:

MW[MatrixNumber]=SELECTLINK(expression)

The compute command is coded as part of the SKIMIJ phase.

Where no route is found for an I-J pair all select link functions will return zero values.

As a general rule, working variables or results of COMP commands may not be used to specify values which form part of a selection expression. The values required by the user must be specified directly in the script, or obtained from scenario keys (by substitution into the script).

This topic discusses:

Selection for particular links

To select demand traversing a link, the expression takes the form

L = ANode-BNode

This identifies all demand traversing the link in the direction from the given A-node to the B-node. To identify demand in either direction along the link a "*" is appended to the specification:

L = ANode-BNode*

Examples:

MW[1] = SELECTLINK(L=1023-1027)

selects demand traversing the link 1023 to 1027 in that direction, whereas:

MW[2] = SELECTLINK(L=1025-1028*)

selects demand traveling along the link in either direction.

The expression used may contain a list of link specifications, which are separated by commas (or alternatively spaces). If a list is defined, using any one of the links turns the selection criterion to "true". For example:

MW[3] = SELECTLINK(L=101-102,104-105*,107-109)

selects demand if one of the links 101 to 102, 104 to 105, 105 to 104 or 107 to 109 is on the path. The use of comma between link specifications is optional, and may be replaced by a space character.

Selection criteria which require the use of two or more links are described below.

Select line

To select demand using a particular line, the expression takes the form:

LINE = LineName

Use of two or more line names in a list is permitted, and when used the selection criteria is true if any one of the listed lines is used.

Line names may contain masks of a single trailing "*" or one or more trailing "?". The leading nonmasked portions will then be compared for selection purposes. Use the "*" for multiple columns. For example:

LINE = MUNI*

matches line names such as MUNI, MUNICENTRAL, and MUNINORTH. Use the "?" for single characters. For example:

LINE = MUNI-??

would match line names MUNI-01 and MUNI-02. Examples:

MW[1] = SELECTLINK(LINE=RED1)

selects demand using the line which has name RED1.

MW[2] = SELECTLINK(LINE=A*,B*)

selects lines with names beginning with either A or B.

Select node

To select demand passing through a particular node, the expression takes the form:

N=NodeNumber

Lists of nodes may be used, and ranges of nodes may be specified using ‘-‘. Examples:

MW[1]=SELECTLINK(N=107,200-208)

selects demand which passes through node 107 or any of the nodes in the range 200 to 208. The selection considers transit legs which start at, pass through, or finish at the specified node(s).

Select mode

To select demand which uses a particular mode, the expression takes the form:

MODE = ModeNumber

The mode number may be a transit mode (in which case demand using lines of that mode are selected) or can be a nontransit mode. Lists and ranges may be used when specifying the required modes. Tests using not equals (!= or <>) are permitted with mode conditions.

For example:

MW[5] = SELECTLINK(MODE=3,5,7-9)

selects demand which uses any of modes 3,5,7,8 or 9.

Select operator

To select demand which uses lines from a particular operator, the expression takes the form:

OPERATOR = Number

Lists and ranges of numbers may be used when specifying the required operators. Tests using not equals (!= or <>) are permitted with operator conditions.

Example:

MW[7] = SELECTLINK(OPERATOR=3)

selects all demand on lines run by the operator having an identification number of 3.

Combining selection criteria together

You can combine two or more select-link criteria to form compound conditions. Use the "and" operator (& or &&) and "or" operator (| or ||) to combine simple conditions.

The use of | (or) operators may sometimes be avoided when the same data type is referred to in both tests. The example:

MW[5] = SELECTLINK(L=401-402 | L=421-422)

gives exactly the same results as:

MW[5] = SELECTLINK(L=401-402,421-422)

Two tests based on link-selection criteria may readily be combined using the "and" operator. For example:

MW[3] = SELECTLINK(L=101-103&L=108-109)

selects demand which travels along both link 101 to 103 and 108 to 109. In evaluating this test it does not matter which of the links is traversed first; it is use of both of them which sets the selection to "on".

selects demand which uses both line RED2 and also line BLUE7. Again, which is used first does not matter.

When combining tests using two data types it is also necessary to consider how the conditions interrelate. As an example, consider how you might combine a test on a link with a test on a line. You might wish to specify that the link was used (somewhere in the trip) and that the line was also used (at some point in the trip). These conditions are independent of each other. Alternatively the requirement may be that the line was used to traverse the specified link; this is a "simultaneous condition" where two or more conditions must all apply at one point in the trip, and such conditions are considered in the following section.

Where the selection criteria are independent, use of the "and" operator is appropriate. For example:

MW[6] = SELECTLINK(L=211-234&LINE=GREEN)

treats the two conditions as independent tests, so that demand is selected if the link 211 to 234 is traversed and also (but not necessarily at the same time) the GREEN line is used.

Using simultaneous selection criteria

Where two conditions apply simultaneously the operator, use "+" to combine them. Such simultaneous conditions are combined together before any "&" and "|" operators are evaluated. For example:

MW[2] = SELECTLINK((L=101-102 + LINE=RED)&(L=201-202 + LINE=BLACK))

selects demand which uses line RED on link 101 to 102 and also uses line BLACK on link 201 to 202. The use of brackets around each simultaneous condition is optional; brackets ease reading of the condition groups, and may be omitted without affecting the results.

The "+" operator is typically used to combine:

Link conditions with line, mode, or operator conditions
Node conditions with line, mode, or operator conditions
Any condition with criteria determining type of movement or leg considered (as described below)

Use of the "not" and "not equals" operators

Use care with negated conditions. The "not equals" operator (!= or <>) is not permitted in link or node expressions (that is, L or N expressions).

When using negated tests with line conditions, it is often appropriate to use an expression of the form !(LINE=RED)which means "did not use line RED".

Use of "not equals" may give results which do not exactly match your intentions. For example, the condition LINE!=RED means "used lines other than RED". If considering a two-leg trip where line RED used on the first leg, then this condition would be true as some line other than RED is used on the second leg.

Selecting particular types of movement

The normal operation of select link considers transit legs (passing along a link or at a node), unless mode selection criteria have been specified. You can amend this default behavior, allowing the selection criteria to consider particular types of movement. These are specified in the select link expression by a TYPE keyword (which is usually part of a simultaneous condition, linked by "+" operator to the associated link or node condition).

For conditions using link selection (that is, L= conditions) the TYPE keyword can take either of the following values.

NTINCLUDED — To consider transit and nontransit legs traversing the link
NTONLY — To select just nontransit legs

The link specification will select nontransit legs which either traverse the specified link (if XN values are available in NTLEG data for intermediate nodes), or when no XN data is available the start and end points of the nontransit leg correspond to the link specification. The TYPE keyword may not be followed by a "not- equals" (!= or <>) operator.

For conditions using node selection (that is, N= conditions) the TYPE keyword can take the following values

THRU — To consider transit legs passing through the node
BOARD — To consider transit legs boarded at the node
ALIGHT — To consider transit legs alighted from at the node
NTTHRU — To consider nontransit legs passing through the node. The nontransit legs selected will be those which have the specified node in their list of XN values.

The condition may use a list of two or more of these settings to select movements where any of the listed types apply. The TYPE keyword may not be followed by a "not-equals" (!+ or <>) operator.

The following examples illustrate use of the TYPE keyword:

MW[1]=SELECTLINK(L=101-102+TYPE=NTINCLUDED)

Selects all journeys travelling along link 101 to 102, whether using a transit line or nontransit (for example, walking).
MW[2]=SELECTLINK((N=123+TYPE=ALIGHT)&(N=123+TYPE=BOARD))

Selects all journeys which both alight and board at node 123 (that is, they make an interchange between lines at that node).
MW[2]=SELECTLINK(N=123+TYPE=ALIGHT)

Selects all journeys which alight at node 123; following that they may board another line there, walk to another node to board a line, or egress from the public transport system to reach a destination zone.
MW[2]=SELECTLINK(N=123+LINE=X+TYPE=BOARD)

Selects just the demand boarding line X at node 123.
MW[5]=SELECTLINK(N=579+TYPE=THRU,ALIGHT)

Selects all transit demand arriving at node 579 (whether they alight or continue on the line).

Obtaining matrices of proportion or percentage of demand meeting a criterion

The select process typically returns the demand for an I-J pair which satisfies a selection criterion. The proportion of demand meeting the criterion may be obtained by including the PROBABILITY keyword in the expression (that is, PROBABILITY=T). Similarly, percentages may be obtained by using the PERCENT keyword (that is, PERCENT=T). As an example:

MW[3]=SELECTLINK(LINE=TRAM1,PERCENT=T)

Returns percentage values for each I-J pair which use the line TRAM1.

Loading the select link demand

The select-link process may load the portion of total demand meeting a select link criterion, rather than loading the entire demand as specified by the parameter TRIPSIJ.

This is invoked by including the keyword and setting LOAD=T in the select link expression. As an example:

MW[2]=SELECTLINK(L=303-307*,LOAD=T)

Although a program run may include several SELECTLINK functions, only one of these may be used to trigger select-link loading.

Where crowding is modeled, the restriction using selection criteria applies to the last iteration, so the crowding is based on complete loadings.

If skims are obtained when performing select-link loading, then the skims are obtained for all evaluated routes (that is, they are not restricted to the subset of routes which match the select link criteria).

Loading analyses

During the loading-analyses process, the Public Transport program presents further reports of transit and nontransit passenger loadings than those performed during the loading process. Any request for loading analyses automatically invokes a loading process.

As with the loading process, demand stratified by user class produces loading analyses for each class.

Loading analyses are associated with the MATI phase. The analyses currently available are:

Transfers between modes

Reports produced if loading is performed and output to the main print file:

Passenger transfers between transit and nontransit modes
Passenger transfers between transit modes

Transfers between operators

Report produced if loading is performed and output to the main print file:

Passenger transfers between transit and nontransit modes

Stop-to-stop movements

Several types of stop-to-stop movements may be extracted, either for a selection of stops, or groups of stops:

First entry/last exit
Adjacent
All on/off combinations

The first two can be obtained by mode or for all modes. You can save this analysis to a DBF file with FILEO STOP2STOPO.

Crowd modeling

During the crowd-modeling process, the Public Transport program iteratively balances loaded demand against capacity. At each iteration, the program completes the route-evaluation and loading processes, which are repeated for all user classes, and then adjusts the costs in the model to reflect the assigned loads. The iterative process may use either, or both, of the crowd modeling procedures:

Link travel time adjustment
Wait time adjustment

See Crowding for information about the theory of crowding models.

When crowd modeling is performed, the results obtained from the last iteration (in the form of loaded flows, printed reports, and skims) provide the model outputs.

Timetable-based modeling

Timetable-based modeling uses the actual timetable for services as its basis. The possible paths from an origin to a destination are the alternative combinations of routing & timing calculated examining the timetable data associated to the services.

The term path is used to mean a route which is followed using a set of departure and arrival times at each stop. E.g., if between zone I and zone J travelers can use only one single route with a line departing at 09:10, 09:25 and 09:45 in one hour between 09:00 and 09:59, then there would be 3 distinct paths in the hour from zone I to zone J, even if there is however just one underlying route.

These possible paths are enumerated and then evaluated in a twostage process, similar to the headway-based approach:

Route Enumeration (identification)
Route Evaluation

Despite the similarities, the network simplification and route enumeration of headway-based and timetable-based approaches

are different. Also, the route enumeration logic and algorithms are different, with additional decisions of acceptable Departure and Arrival time at each stop node during the enumeration process.

Demand data is in the form of one matrix per user class for the period. The demand from one origin to a destination is distribute over the evaluated routes using a discrete choice probabilistic model (Kirchhoff or Logit), based on the generalized cost of the alternative routes.

The timetable-based model runs for a user-specified time period or point in time, seeking journey opportunities starting in that interval or at the time point.

Day types can also be specified to model service variations from day to day (e.g. Weekday, Saturday and Sunday could have different schedules).

At the current state of development, timetable-based modeling and headway-based modeling are two alternative approaches that cannot be combined for the representation of the Public Transport system. Moreover, crowding cannot be used when implementing the timetable-based approach.

See "Timetabling" for information about the theory and implementation of timetable-based models.

Footnotes

Produced for each zone pair. Can be reported by zone pair, but not saved.